The Output type introduced on top is only used for this exercise, it's the only one where we need to assert the values of different types. It's a little verbose, but it's the best I could come up with.

This is going to make any test failures hard to read. Not sure what the other solutions are, but maybe asserting on all the fields all the time, instead of picking out one for each assertion?

Here is an example of a test failure (I changed total to add 10 seconds)

↓ SplitSecondStopwatch
✗ supports very long laps

    Ok (CurrentLap "01:23:45"), Ok (PreviousLaps ["01:23:45"]), Ok (CurrentLap "04:01:40"), Ok (Total "05:25:35"), Ok (PreviousLaps ["01:23:45","04:01:40"]), Ok (CurrentLap "08:43:05"), Ok (Total "14:08:40"), Ok (PreviousLaps ["01:23:45","04:01:40","08:43:05"])
    ╷
    │ Expect.equalLists
    ╵
    Ok (CurrentLap "01:23:45"), Ok (PreviousLaps ["01:23:45"]), Ok (CurrentLap "04:01:40"), Ok (Total "05:25:25"), Ok (PreviousLaps ["01:23:45","04:01:40"]), Ok (CurrentLap "08:43:05"), Ok (Total "14:08:30"), Ok (PreviousLaps ["01:23:45","04:01:40","08:43:05"])
    
    The first diff is at index 3: it was `Ok (Total "05:25:35")`, but `Ok (Total "05:25:25")` was expected.

I think it doesn't read to bad, it's clear where the first problem is, and it's very clear that it's about total. What do you think?

maybe asserting on all the fields all the time, instead of picking out one for each assertion?

I was following the problem specs as close as I could, they are only asserting those specific values, it's easier to maintain in the long run.
Also, if I wanted to assert on all the fields, it would not be possible to treat this as an opaque type problem anymore, we would have to expose the inner structure.

It doesn't read too bad, but the types don't relate to anything in the code, which is confusing. Maybe using strings would fix that?
Following the problem specs makes sense.

what are the underscores for?

Because state is an exposed function, so we are not allowed to shadow it. I was a bit lazy with the _ notation, that's the kind of thing you see in Haskell, but I didn't want to be too verbose.
Would you have a better suggestion?

I've seen aState used before, which fits with it being an instance of the state type. theState sometimes as well.

Maybe we could use a finite state machine here, instead of using Result (and in the other places)?

I was trying to stick to the specs.
How would you write a finite state machine though? With phantom types? Or just by ignoring error instructions?

I haven't looked at the problem specs to be fair, but this code definitely looks like it should be one. All that error handling for the invalid states/actions is a definite code smell.
Maybe I could mention it on the forum and we can follow it up there if needs be?

I don't feel that strongly about it, but you could check what other people think. I suspect it won't be that easy to change it, and they might suggest to create a new exercise based on finite state machines (which would be cool).
In the mean time, I'll keep it this way.

This is going to make any test failures hard to read. Not sure what the other solutions are, but maybe asserting on all the fields all the time, instead of picking out one for each assertion?